Scenario
A user calls in reporting they cannot log into their workstation. Their account is testaccount on WS01. The goal is to diagnose why the account is not functioning and restore it to operational status without knowing in advance what was broken.
Environment
- Proxmox
- Network Lab LAN
- NetLab.private
- WS01
- DC01
Breaking the Account
To simulate the break, two PowerShell commands are run on DC01. The command Disable-ADAccount -Identity testuser disables the account entirely. The command Set-ADAccountPassword -Identity testuser -Reset -NewPassword (ConvertTo-SecureString "wrongpassword1" -AsPlainText -Force) resets the account password to an unknown value. With both commands executed, the account is disabled and the password has been changed without the user's knowledge, simulating two separate issues that must be identified and resolved independently.
Identifying the Problem on the Workstation
Navigating to WS01 and attempting to log in immediately surfaces the first issue. A warning message appears stating that the account has been disabled.
The next step is to return to DC01 and investigate the account. In Server Manager, navigate to Tools and open Active Directory Users and Computers. Locate the testaccount account under the Users container and open its properties.
Under the Account tab, there is a checkbox labeled Unlock Account. This option is specifically for accounts that have been locked out due to too many failed login attempts and is not the correct fix here. The account in this case was administratively disabled, which is a different condition entirely. To re-enable it, right click the account from the Users list and select Enable Account. The account is now active again.
Returning to WS01 and attempting to log in again shows that the disabled error is gone, but a password error now appears. Since the password was changed as part of the break, it must be reset. Back on DC01, right click the account and select Reset Password. Assign a temporary password and ensure the User must change password at next logon checkbox is enabled. This forces the user to set their own password immediately upon login, which is standard help desk practice rather than leaving a temporary password in place.
Logging into WS01 with the temporary password triggers a forced password change prompt. After setting a new password, the account is fully restored. A ping to 10.10.10.10 confirms that domain connectivity is intact and the workstation is still communicating with DC01.
Your test account has been restored!
Problems Encountered
The main point of confusion during this lab was the difference between a locked account and a disabled account. The Unlock Account checkbox in account properties only activates when an account has been locked out automatically by the system, typically after exceeding the failed login attempt threshold defined in the domain password policy. An administratively disabled account does not trigger that checkbox and must be re-enabled through the right click context menu instead. Knowing the difference matters in a real environment because they have different root causes and different resolution paths.
Closing Notes
This lab reinforced the distinction between two account states that look similar on the surface but have entirely different causes and fixes. A locked account is a system response to suspicious or repeated failed activity, while a disabled account is a deliberate administrative action. In a real help desk environment, misidentifying one for the other wastes time and can lead to incorrect escalations.
The Kerberos log observation was an unexpected bonus from this lab. Seeing Event ID 4769 generated during a successful login makes the authentication process tangible rather than abstract. Kerberos is running silently in the background of every Active Directory login, and understanding what its log entries look like under normal conditions is the foundation for recognizing when something is wrong, which becomes critical in later security labs.
Requiring the user to reset their own password on next logon rather than leaving a known temporary password in place is a real security practice. It ensures that no one other than the user ever knows their active credentials, which limits exposure even in trusted environments.
Terms & Concepts
Kerberos
The default authentication protocol in Active Directory environments. When a user logs in, Kerberos issues a Ticket Granting Ticket (TGT) which is then used to request access tokens for specific network resources without re-entering credentials.
Event ID 4769
A Windows Security audit event logged when a Kerberos service ticket is requested. It records the account name, service name, encryption type, and result code, making it a key event for both normal authentication monitoring and detecting Kerberoasting attacks.
Event ID 4625
A Windows Security audit event logged when an account fails to authenticate. It captures the failure reason, logon type, and source, and is a primary indicator used to detect brute force attempts and credential misuse.
MSDS-SupportedEncryptionTypes
An Active Directory attribute that defines which Kerberos encryption types an account or computer supports. Values appear in Event ID 4769 entries and indicate the encryption negotiated during ticket issuance. A value of 0x0 means default encryption was used successfully.
Password Reset on Next Logon
A flag set on a user account that forces a password change immediately upon the next successful login. Used by help desk staff when resetting credentials so that only the end user ever knows their active password.
Ticket Granting Ticket (TGT)
An encrypted credential issued by the Kerberos Key Distribution Center upon successful authentication. The TGT is used to request access to specific services without the user having to re-authenticate, and has a limited validity period before it must be renewed.
Domain Password Policy
A Group Policy setting that defines password requirements across the domain, including minimum length, complexity rules, expiration periods, and the lockout threshold after failed login attempts. Applied uniformly to all accounts unless a fine-grained password policy is in place.